Taking (Computer) Architecture Seriously

There seems to be little consensus on what an agent architecture is. In this paper I will talk about architectures in computer design, and programming languages, and what their distinctions are. I will then discuss agent architectures relative to that distinction. Finally, I will discuss recent work I have done on building better computer architectures for agency. One of the problems with writing about agent architectures is that I don’t have a good sense of what an agent architectures are supposed to be, much less how to evaluate them or what the right one is. In this position paper, I’ll compare agent architectures to computer architectures and programming languages, which I feel I understand somewhat better. Computer architectures and programming languages Computer architecture means either the computer’s instruction set or how that instruction set is implemented by a fixed collection of finite-state circuits with fixed data paths. In designing an architecture, the goal is to find simplest possible design that is still Turing complete and that has the best possible average case performance on typical programs, whatever "typical" might mean. Programming language design, by contrast, is how you specify computations, independent of what primitive circuits are used to carry them out. In programming language design, the goal is to come up with a set of features that allow typical programs to be specified as concisely as possible, yet which is still efficiently mappable onto the underlying architecture’s instruction set, again, in the "typical" case. Computer architectures and languages are both problem-independent, at least partially. Most architectures can run any program and most languages can describe any algorithm. When you switch from one program to another, the architecture is a mechanism that remains the same, and the language is a means of description that remains the same. Computer architecture and language design, as practices, are driven by the same pair of complementary pressures to add and remove features. Adding a new feature can dramatically speed up or simplify those programs that can make use of it. On the other hand, it may uniformly slow down other programs by introducing additional overhead, or stretching the necessary length of a clock cycle. Adding GC and run-time type checking to a language greatly improves some things, but in most cases also imposes some level of overhead on all programs, regardless of whether they need or use the new features. Computer architects and language designers search feature space for the feature combination that maximizes average performance. Average performance, however, can only be defined relative to a particular mix of programs and their frequency of use. Experimental architecture work is therefore often based on explicitly choosing a set of "representative" programs, simulating them to gather statistical data about the relative frequency with which they perform different types of operations or could use certain architectural features, and then using that data in the design and evaluation of architectures. The chosen architecture is highly sensitive to the choice of programs: a set of benchmarks based on Unix programs and a set of benchmarks based on symbolic programs will give you radically different recommendations on whether to build a SPARC or a Lisp machine. To summarize: a computer architecture or programming language: (1) makes some things easy to do and makes other things hard to do; (2) draws its efficiency as much from its selection of features not to provide as to provide; and (3) can typically only be evaluated relative some agreed-upon mix of programs.